WebRTC (Web Real-Time Communications) is an open project that aims to add real-time communications capabilities to Web browsers via a JavaScript Application Programming Interface (API). WebRTC offers web application developers the ability to write rich, real-time multimedia applications on the Web, without requiring plugins, downloads, or installs. For example, WebRTC may enable peer-to-peer real-time communication between browser-based applications regardless of the relative location of the target peers (e.g., on the same device, in the same private network, both behind distinct firewalls, etc.).
WebRTC adopts a technique called Interactive Communication Establishment (ICE), which allows for target peers in an Internet Protocol (IP)-based communications session to discover the best possible media path between them. This may be useful in the sense that an ICE implementation is a turnkey solution for Network Address Translation (NAT) traversal that requires no prior knowledge of the type of NATs or firewalls that may lie between the two target peers.
ICE leverages the Session Traversal Utilities for NAT (STUN) and Traversal Using Relays Around NAT (TURN) protocols. STUN is an IP-based protocol by which a target peer can discover whether it is behind a NAT traversal box. By contacting a known server in the open Internet and receiving a response back, the target peer can compare its own IP address with the IP address that the STUN server detected as the originating IP address for the STUN message. In this manner, the target peer can quickly determine if it is behind a NAT.
In an example, a STUN request message is sent by one of the target peers (also known as a peer) to a known STUN server on the public Internet. The STUN server's IP address may be known a priori by the peer or is discoverable (e.g., with the help of a Domain Name System (DNS) service). When the STUN server receives the STUN request from the peer, the STUN server sends back a STUN response message that includes the originating IP address. If a NAT was present between the peer and the STUN server (e.g., the peer is on a private network), the IP address in the STUN response message will not match the peer's IP address on its private network. This kind of messaging only partly solves the problem of NAT traversal. A NAT may be server-reflexive in that a one-to-one mapping exists between the peer's private IP address and the IP address provided by the NAT on behalf of the peer to all destinations in the public Internet. Many NATs, however, are symmetric—there is a unique IP address mapping for the peer for each of its destination IP addresses on the public Internet. Therefore, a mechanism that moved beyond simple IP address discovery was needed. As a result, the TURN protocol was developed.
TURN solves the problem of a NAT'ed peer receiving traffic from any other target peer on the Internet by setting up a TURN server on the public Internet that relays traffic to and from the NAT'ed peer. For example, the originating peer initially sends a “TURN Allocate” request usually without necessary fields to ensure message integrity. In response the TURN server sends an “Allocate Error” message with necessary values for future messaging (e.g., nonce for hashing), after which the originating peer can resend the “TURN Allocate” message with the necessary message integrity and receive a “TURN Allocate” response, where the NAT'ed peer can not only determine its presence behind a NAT but also be allocated a relayed IP address from the TURN server that can be used to set up communication with other peers.
ICE provides a framework around the use of STUN and TURN so that two peers can negotiate the best possible media path between them in the presence of NATs. Based on each peer's detection of IP addresses and ports that can be used to contact them, “candidate pairs” of IP addresses/ports are tested and ranked in terms of ICE client-specified priority. The ICE standard provides an example algorithm for prioritization. As a result, ICE defines an offer/answer mechanism for negotiating the parameters of the communication session between peers based on a protocol (e.g., Session Description Protocol (SDP)).